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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


1. Introduction 


The Internet Message Access Protocol, Version 4 [IMAP4] contains the 
AUTHENTICATE command, for identifying and authenticating a user to an 
IMAP4 server and for optionally negotiating a protection mechanism 


for subsequent protocol interactions. This document describes 
several authentication mechanisms for use by the IMAP4 AUTHENTICATE 
command. 


2. Kerberos version 4 authentication mechanism 


The authentication type associated with Kerberos version 4 is 
"KERBEROS_V4", 


The data encoded in the first ready response contains a random 32-bit 
number in network byte order. The client should respond with a 
Kerberos ticket and an authenticator for the principal 
"imap.hostname@realm", where "hostname" is the first component of the 
host name of the server with all letters in lower case and where 
"realm" is the Kerberos realm of the server. The encrypted checksum 
field included within the Kerberos authenticator should contain the 
server provided 32-bit number in network byte order. 


Upon decrypting and verifying the ticket and authenticator, the 
server should verify that the contained checksum field equals the 
original server provided random 32-bit number. Should the 
verification be successful, the server must add one to the checksum 
and construct 8 octets of data, with the first four octets containing 
the incremented checksum in network byte order, the fifth octet 
containing a bit-mask specifying the protection mechanisms supported 
by the server, and the sixth through eighth octets containing, in 
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network byte order, the maximum cipher-text buffer size the server is 
able to receive. The server must encrypt the 8 octets of data in the 
session key and issue that encrypted data in a second ready response. 
The client should consider the server authenticated if the first four 
octets the un-encrypted data is equal to one plus the checksum it 
previously sent. 


The client must construct data with the first four octets containing 
the original server-issued checksum in network byte order, the fifth 
octet containing the bit-mask specifying the selected protection 
mechanism, the sixth through eighth octets containing in network byte 
order the maximum cipher-text buffer size the client is able to 
receive, and the following octets containing a user name string. The 
client must then append from one to eight octets so that the length 
of the data is a multiple of eight octets. The client must then PCBC 
encrypt the data with the session key and respond to the second ready 
response with the encrypted data. The server decrypts the data and 
verifies the contained checksum. The username field identifies the 
user for whom subsequent IMAP operations are to be performed; the 
server must verify that the principal identified in the Kerberos 
ticket is authorized to connect as that user. After these 
verifications, the authentication process is complete. 


The protection mechanisms and their corresponding bit-masks are as 
follows: 


1 No protection mechanism 
2 Integrity (krb_mk_safe) protection 
4 Privacy (krb_mk_priv) protection 


EXAMPLE: The following are two Kerberos version 4 login scenarios 
(note that the line breaks in the sample authenticators are for 
editorial clarity and are not in real authenticators) 


* OK IMAP4 Server 

A001 AUTHENTICATE KERBEROS_V4 

+ AmFYig== 
BACAQU5EUKVXLKNNVS5FRFUAOCASho84kLN3/IJmrMG+25a4DT 
+nZImJ jnTNHJUt xAA+o0KPKfHECAFs 9a3CL50ebe/ydHJUwYFd 
WwuQ1MWiy6lesKvjL5rL9WjXUb9MwT 9bpObYLGOKi1Q0h 

+ or//EOAADZI= 

DiAF5A4gA+oOIALUBkAAmw== 

S: A001 OK Kerberos V4 authentication successful 


S 
Cs 
Sit 
C 


QU 
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S: * OK IMAP4 Server 

C: A001 AUTHENTICATE KERBEROS_V4 

S: + gcfgCA== 

C: BACAQU5EUKVXLKNNVS5FRFUAOCASho84kLN3/IJdmrMG+25a4DT 
+nZImJ jnTNHJUt xAA+o00KPKfHECAF's 9a3CL50ebe/ ydHIUWYFd 
WwuQ1MWiy6lesKvjL5rL9WjXUb9MwT 9bpObYLGOKi1QOh 

S: A001 NO Kerberos V4 authentication failed 


3. GSSAPI authentication mechanism 


The authentication type associated with all mechanisms employing the 
GSSAPI [RFC1508] is "GSSAPI". 


The first ready response issued by the server contains no data. The 
client should call GSS_Init_sec_context, passing in 0 for 
input_context_handle (initially) and a targ_name equal to output_name 
from GSS_Import_Name called with input_name_type of NULL and 
input_name_string of "SERVICE:imap@hostname" where "hostname" is the 
fully qualified host name of the server with all letters in lower 
case. The client must then respond with the resulting output_token. 
If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client 
should expect the server to issue a token in a subsequent ready 
response. The client must pass the token to another call to 
GSS_Init_sec_context. 


If GSS_Init_sec_context returns GSS_COMPLETE, then the client should 
respond with any resulting output_token. If there is no 
output_token, the client should respond with no data. The client 
should then expect the server to issue a token in a subsequent ready 
response. The client should pass this token to GSS_Unseal and 
interpret the first octet of resulting cleartext as a bit-mask 
specifying the protection mechanisms supported by the server and the 
second through fourth octets as the maximum size output_message to 
send to the server. The client should construct data, with the first 
octet containing the bit-mask specifying the selected protection 
mechanism, the second through fourth octets containing in network 
byte order the maximum size output_message the client is able to 


receive, and the remaining octets containing a user name string. The 
client must pass the data to GSS_Seal with conf_flag set to FALSE, 
and respond with the generated output_message. The client can then 


consider the server authenticated. 


The server must issue a ready response with no data and pass the 
resulting client supplied token to GSS_Accept_sec_context as 
input_token, setting acceptor_cred_handle to NULL (for "use default 
credentials"), and 0 for input_context_handle (initially). If 
GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should 
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return the generated output_token to the client in a ready response 
and pass the resulting client supplied token to another call to 
GSS_Accept_sec_context. 


If GSS_Accept_sec_context returns GSS_COMPLETE, then if an 
output_token is returned, the server should return it to the client 
in a ready response and expect a reply from the client with no data. 
Whether or not an output_token was returned, the server then should 
then construct 4 octets of data, with the first octet containing a 
bit-mask specifying the protection mechanisms supported by the server 
and the second through fourth octets containing in network byte order 
the maximum size output_token the server is able to receive. The 
server must then pass the plaintext to GSS_Seal with conf_flag set to 
FALSE and issue the generated output_message to the client in a ready 
response. The server must then pass the resulting client supplied 
token to GSS_Unseal and interpret the first octet of resulting 
cleartext as the bit-mask for the selected protection mechanism, the 
second through fourth octets as the maximum size output_message to 
send to the client, and the remaining octets as the user name. Upon 
verifying the src_name is authorized to authenticate as the user 
name, The server should then consider the client authenticated. 


The protection mechanisms and their corresponding bit-masks are as 
follows: 


1 No protection mechanism 
2 Integrity protection. 

Sender calls GSS_Seal with conf_flag set to FALSE 
4 Privacy protection. 

Sender calls GSS_Seal with conf_flag set to TRUE 


4. S/Key authentication mechanism 


The authentication type associated with S/Key [SKEY] is "SKEY". 


The first ready response issued by the server contains no data. The 
client responds with the user name string. 


The data encoded in the second ready response contains the decimal 
sequence number followed by a single space and the seed string for 
the indicated user. The client responds with the one-time-password, 
as either a 64-bit value in network byte order or encoded in the "six 
English words" format. 


Upon successful verification of the one-time-password, the server 
should consider the client authenticated. 
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S/Key authentication does not provide for any protection mechanisms. 


EXAMPLE: The following are two S/Key login scenarios. 


* OK IMAP4 Server 

A001 AUTHENTICATE SKEY 

+ 

bW9yZ2Fu 

+ OTUQUWE1ODMwOA== 

Rk 9VULBNQUSOIFNPTO4gRk1SIFZBULkgTUFTSA== 
A001 OK S/Key authentication successful 


NANANAN 


* OK IMAP4 Server 

A001 AUTHENTICATE SKEY 

+ 

c21pdGg= 

+ OTUQUWE1ODMwOA== 

BsAY3g4gBNo= 

A001 NO S/Key authentication failed 


NANAMN AN 
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6. Security Considerations 


Security issues are discussed throughout this memo. 
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